1. Field of the Invention
The present invention relates generally to an improved data processing system, and in particular, to a method, apparatus, and computer instructions for identifying unsafe synthetic transactions and modifying parameters in the transactions to allow for automated playback.
2. Description of the Related Art
Performance monitors are used to capture detailed transaction and application performance data for electronic business transactions. Every step of a customer transaction as it passes through an array of hosts, systems, application, Web and proxy servers, Web application servers, middleware, database management software, and legacy back-end software may be monitored and performance characteristic data compiled and stored in a data repository for historical analysis and long-term planning. One way in which this data may be compiled in order to test the performance of a system is to simulate customer transactions and collect performance data to help assess the health of electronic business components and configurations.
As electronic business owners need to ensure that their Web sites are available and meet performance targets, some performance monitors permit these users to manually record and playback business transactions occurring on their Web sites. A recording component captures performance data about actual user transactions that are executed against elements (e.g., Web servers, Web application servers) of the business environment. A playback component executes the recorded transactions to simulate actual user activity. These simulated transactions are known as synthetic transactions. Recording/playback of transactions allows a business owner to determine the manner by which transactions are processed by the various elements of the electronic business, and thus which processes are causing problems and where the processes may be improved.
Certain recorded transactions may be identified by a business owner as “valuable”, meaning that these transactions recorded by the system are transactions that the business owner would want to be synthetically played back and monitored. A problem encountered when playing back recorded transactions is that playback of some transactions may have adverse side effects in the back-end of the enterprise. For example, when a customer purchases a book from an online bookstore, the customer uses a credit card to pay for the book and the recording component of a synthetic transaction engine in the performance monitoring system records the transaction. If, however, the synthetic transaction engine plays back the recorded transaction, a second copy of the book will be sent to the customer and the customer's credit card will again be charged for the book purchase. Synthetic transactions having potentially adverse or destructive consequences if played back are deemed “unsafe” transactions. These unsafe transactions should not be automatically scheduled for synthetic playback without first modifying the transaction to address the adverse side effects.
Currently, a system administrator of a monitoring system addresses this problem by first understanding the Web application and the enterprise back-end. The administrator may modify each unsafe transaction by overriding destructive parameter values in the transaction with test values. A test value is a flagged value that is processed like a customer-entered value, but the test value has no unwanted side effects. An example of a test value is a bogus credit card number that is still processed by a Web service, but no money is added or subtracted from the credit card account. System administrators must currently modify their programming code to check for and override unsafe transactions with safe values at the lower levels (e.g., DB2, Web Services, Java Message Service (JMS), etc.) of the enterprise system. As these safe/unsafe mappings change over time, a system administrator would have to update the code or provide a programming mechanism to update and reflect these new safe/unsafe mappings. As a result, it is very difficult for a system administrator to maintain the logic to check for safe/unsafe transactions and override each type of potential line of logic (e.g., DB2, Web Services, JMS calls, etc.).
Thus, unsafe transactions cannot currently be played back without modification and back-end programming to account for the test values required. Consequently, if a certain transaction does not have test values, the transaction will not be monitored. This situation can be problematic since company management will never know how this monitoring deficiency could potentially impact the business. In addition, system administrators that do not have defined test values to address unsafe transactions may not even realize the limitations of their synthetic transaction coverage. Transaction coverage is the percentage of their critical e-business transactions that are covered by their recorded synthetic transaction coverage.
Therefore, it would be advantageous to have improved mechanism for identifying unsafe synthetic transactions and modifying transaction parameters for automated playback.